devfandomcom-20200223-history
Talk:SpoilerAlert
How to trigger There's no instructions given on how to trigger this function to pop up on a window. I'm not going to rename my pages where I want to use this to Spoiler:Pagename. That's ridiculous. How does SpoilerAlert/Demo trigger it? It is not called Spoiler:Anything (close, but no ":" in "SpoilerAlert". I tried copying the line from the Demo source: " " as it would make sense if the code checked for some div id... but it didn't work. Please advise, Thanks, PS. When I didn't use the nowiki tags on the div id above, this page prompted the Spoiler Alert dialog to pop up. PPS. On both the demo and this page, clicking on No, not yet or Yes please does nothing - the dialog just stays there. I assumed for the demo it was because there was no page data to dispay, but the dialog refused to go away on this talk page. Also this text still showed below the dialog box. So I really don't think this code is working too well. :You don't have to rename your pages. That was just an example. All you need to do, is provide your own isSpoiler function. That function tells SpoilerAlert whether it should display the dialog or not. If you tell me how you want to trigger SpoilerAlert I'll write an isSpoiler function for you! :) :You say, you clicked on both "no" and "yes" but the dialog did not disappear? That's strange. I just tested the demo and it does work for me. Can you tell me what other scripts you're using and where you've added them? -- pecoes 16:23, July 14, 2012 (UTC) Cool! I was just going to try it out on: w:c:ParadiseIslandHD:Upcoming buildings and features and I don't forsee using it on any other page (our site(s) don't really have much use for it - but I happened across your code and thought I'd chuck it on). I have a box at the top of that page, I figured it could still stay there after the dialog pop-up disappears. So how about it triggers on any page that the template is on? Re: What other scripts I have? I just clicked on SpolierAlert/Demo here on this site, so whatever scripts I have on other sites would be irrelevant... I use IE9, it shows the dialog at the top of the page, the clear cache and reload underneath it, and this is a demo text below that. I just opened it in Chrome and it works properly... :Okay, I've modified the template a little. Add this to your MediaWiki:Common.js: window.SpoilerAlert = { isSpoiler: function () { return Boolean($('#spoiler').length); } }; importScriptPage('SpoilerAlert/code.js', 'dev'); :pecoes 16:56, July 14, 2012 (UTC) ::I can confirm that SpoilerAlert is broken in IE9! I'll get back to you when I have a fix! -- pecoes 17:17, July 14, 2012 (UTC) :::Correction: It does work in IE9. I had to clear my cache though. -- pecoes 17:44, July 14, 2012 (UTC) Hi, sorry, was busy elsewhere. It works almost-perfect in Chrome, but in IE9 it just displays the dialog on top of the page, so you can still see the page unhidden, and the buttons do nothing, so the dialog won't go away. Any reason you moved the noinclude tag, as the existing spoiler template now no longer displays its dialog box. I thought it would be cool once the Yes/No dialog disappeared if the Spoiler template still showed its box at the top. Also, like on your demo, if the user presses "No", instead of showing a blank page, it should show the "refresh cache and reload" button - perhaps integrating with the nice-looking existing Spoiler template. ie. If they press "Yes", the neat-spoiler box remains up the top as a friendly reminder, if they say "No", only that box shows with an option to reload. In IE9 I pressed Ctrl-F5, etc, but it never worked, not even the Demo page. It will need to work for everyone first go, we can't expect users to go through some IE menu, cache-clearing just to get a Yes/No dialog to work... But since I last looked and I got busy, now neither the Yes/No or old Spoiler Template show up...??? I just wantesd to use it because it looked really professional for our website. But if it's too complicated, just a simply Nav Box will suffice: As in: <-- automatically hidden by default --> Spoiler Alert Message Wrap around Page Content here - Optionally, just certain / multiple sections can be hidden... Spoiler Alert Message - continue if you dare! Wrap around Page Content here - Optionally, just certain / multiple sections can be hidden... es]] 21:27, July 14, 2012 (UTC) ::I've been making all these test with IE for nothing haven't I? You already decided to give up on SpoilerAlert haven't you? ::pecoes 22:18, July 14, 2012 (UTC) # Re: But I see that your wiki has been migrated to 1.19 #* It doesn't matter what version of MediaWiki "my" w:c:ParadiseIslandHD site is using - I see the same problem on the Demo on dev wiki. And I looked at it first a few weeks ago and saw the same problem. I've just learnt a bit more about js since then and decided to have a go at using it. # Re: "It may be a good idea to postpone the installation of SpoilerAlert until Monday or Tuesday" ## I don't think the issue is related to the MediaWiki version... ## I have to postpone the installation until it works reliably. Any future testing I can do on the dummy site w:c:ParadiseIslandAndroid # Re: If you'd rather do it now, use Chrome #* I can't control what Browser a thousand other visitors use! The page needs to work for everyone regardless of browser. # Re: I've been making all these test with IE for nothing haven't I? #* Not at all, you're not expecting that I was going to be the only person to use are you?? #* Besides, for almost anything there are always alternative ways of achieving the same result, not everyone will want your method. ## Re: You already decided to give up on SpoilerAlert haven't you? ##*Not necesarily. I am dynamically working on many projects, pushing the bounds of wikitext. But as I said, if something's not working, I can't leave a broken page sitting there. So I found an alternative at least for now. ##*As I said, I think your dialog box looks really professional. I don't know what the problem is, you say it works with IE9 for you, but it obviously doesn't for everyone. You also said you saw the problem first before clearing the cache - hopefully that might be a clue as to what the problem is. ##*To be honest, if you sort out the problem, I don't know if I'll use it now on that page or if I'll stick with the hidden NavFrame. I accidentally made it look that way with the Show(Expand) below the header, but now that I have, I think it actually looks really great, and it just works, so I might just leave it that way. ##*But I re-iterate, you shouldn't be working on it just for me!!! I've pointed out a couple of issues for you. I first came across it a while ago but because it wasn't working I ignored it. It was only because I just learnt a little more about common.js that I queried the issue - otherwise I would have just moved on. It's entirely possible several others have come to use it but ignored it because it's not reliable. But now that anyone looking at this page knows that you are actively working on it and fantastically communicating to iron out issues, others may want to look into it again. ##*As I said, "my" site really has no need for it at all, I just wanted to use it to make it look "profressional", but get it working reliably and there will be many from all the TV-shows wikias that might find it useful! Except one issue is that it hides the whole page wheras my "workaround" can be used selectively anywhere and multiple times on one page. # Even if I do stick with my workaround, I'd be glad to help with testing and feedback. ## Besides it not working for me on IE9 for whatever reason, the biggest issue I think is "Installation documentation". ##*Your Installation says to simply importScriptPage which will trigger if the pagename is Spoiler:pagename, but no documentation for alternatives. And then you give Options to change the text such as alternative languages, but we are unable to make those changes using importScriptPage - we'd need to change the source which will affect everyone, or copy and paste the whole js which will no longer update any changes, so the instructions contradict each other. ##*Like the ShowHide/code.js, you need to keep the import option and add the following features and document them: ##*#Add localisation languages and allow the user to add to their js a var SpoilerConfig = {en: {yes: "accept", no: "protect me!", warning: "warning message"}}; customisation. ##*#Add "trigger" options to the source instead of you customising some js for each individual- eg: Include in the source as you have a trigger to launch if the pagename is Spoiler:pagename, but add to the source a trigger if the page is in Category:Spoiler and also if there is an ID="Spoiler". ie. You want it so people can just drop in the importScriptPage line and have it work flexibly without the need for developer interaction. # I'd say in developer terms, this would be at Beta Version 0.9. It needs a little more work before it gets to RTM 1.0 and I look forward to that. # There are still several issues with ShowHide, in particular how the "buttons" are just plain bracketed-text and no-one can get the bracketed-text-buttons to go where they want, and pressing them changes the centering of the text around them because the text changes width, and in comparison the best thing about SpoilerAlert is the professional use of buttons. #* What I really want to see - is a ShowHide NavFrame method of wrapping sections to show/hide with its localisation options, but with Show and Hide being real buttons like yours. (I also think ShowHide needs improving, you should not be forced to change the labels across your whole site in a var in common.js. Just like you can set the Header in NavHeader, you should be able to set NavButtons = Show|Hide / expand|collapse / reveal|hide / etc, per individual page. : Very well. My last reply was a little short-tempered. I've been getting tons of bug reports for all of my scripts in the last few days and in each and every case the culprit turned out to be the upgrade. That's aggrevating. Especially since there's ultimately nothing I can do. : And I'm still not convinced that the upgrade is not the cause of your problems. Just because you use a user-script and not a site-script doesn't mean the upgrade won't affect you. I hear that Dopp (from Wikia Staff) has admitted there are also problems with user-scripts - mostly caching problems. There must be a reason why the code works for me in IE9 in a 1.16 environment, but not for you in IE9 but in a 1.19 environment. : I've followed your suggestion to rewrite the documentation to feature the triggers more prominently and make the language customization stand out a little more. Let me know if you think it's better now! : With the upgrade MediaWiki's build-in collapsible elements become available. By default it looks almost exactly like ShowHide, but according to the manual it should be possible to create a custom button if you give it the classes mw-customcollapsible and mw-customtoggle. With that solution you'd get the best of ShowHide and SpoilerAlert: a collapsible area with nice looking buttons. It does require a bit of hand work though. If you decide to go that route and need help, let me know! I would be very interested in the outcome myself! -- pecoes 11:05, July 15, 2012 (UTC) :: Re: "And I'm still not convinced that the upgrade is not the cause of your problems. ... There must be a reason why the code works for me in IE9 in a 1.16 environment, but not for you in IE9 but in a 1.19 environment." :: Absolutely - I can understand some code (and have written some simple code) but I am not a programmer. All I can do is give detailed feedback as a user to assist you to assist us :-). :: I am not arguing, but I am letting you know that I have jumped on other "clean" computers, with nothing cached, without logging on, with nothing to do with ParadiseIsland, and I have just gone to SpoilerAlert/Demo and it doesn't work - the page loads and the dialog box sits on top without hiding the page, and the dialog won't go away. :: Re: class=mw-collapsible - I tried that in my collapsible tables the moment it came out and reverted to importShowHide's class=collapsible because mw-collapsible does not have the option to collapse by default, the buttons seemed no better, and were not customisable (at least if they are options, none of those options were documented). :: Re: "I've been getting tons of bug reports for all of my scripts in the last few days and in each and every case the culprit turned out to be the upgrade." - Quite likely, its not just your scripts, even such built-in things as Tabview is completely screwed up, and my Forum bug-report has gone ignored so far; Slideshow doesn't work any more, and my Forum bug-report has gone ignored so far; and Wikitable class styles have changed and they're telling use we need to change our own css settings to work around this. We just need to know if the other issues like that are going to be fixed soon or if we need to manually implement workaround fixes on the thousands of wikis in existence. It's amazing how so many issues have come through the upgrade after all their extensive testing and progressive roll-out pre-upgrade. :: Even if SooilerAlert has just worked for me straight out of the box, it's possible I might not have used it on my wiki as NavFrame seems better-suited to my purpose, but you and the ShowHide people should work together - you're buttons are so much mor professional and your cursor turns into a pointer, but the NavFrame is more customisable and flexible and can hide just certain sections of the page and it works with the upgrade. ::: I've been thinking the same thing about ShowHide. I don't like the text link in square brackets either. Maybe it would be for the best to do away with SpoilerAlerts dialog altogether and join the ShowHide developers to add buttons - at least as an option - to their script. ::: I'd love to play around with MW 1.19's collapsible elements and then rewrite SpoilerAlert and/or ShowHide from scratch - if this feature lives up to its promise. But I will wait with that until my test wiki gets upgraded so I can try this stuff "at home" - so to speak. ::: Forgive me if I don't look into that IE9 bug anymore. I don't think I'll further support this script in its current form. ::: The SlideShow and TabView never worked for me btw. I've filed bug reports for both months ago. But I made the mistake of mentioning that I use NoScript. They told me they cannot support third party software. :::pecoes 02:10, July 18, 2012 (UTC) General questions #Any plans to make a version of this script that doesn't hide the entire page, rather, it only hides specific content on the page? (For context, I have w:c:dragonage:Template:Spoiler in mind.) #Might be a nice touch to add a customization option for whether or not the cookie is set. Some people might want the content to be collapsed on every single page load (even if the person has read it before). — Mathmagician (message wall) 22:00, July 15, 2012 (UTC) :#Good idea. It's been suggested to me before, too. There's a small problem though: That would only work if people would wrap the spoiler content in a specific container. That's quite different from the current approach. My understanding is that most use a category to identify the spoiler. I don't think this script has many users, but how many, I don't know... :#You're the first person to mention that. Is that a general proposal or do you want to actually use this script? :pecoes 22:50, July 15, 2012 (UTC) ::These are more of general ideas, rather than a personal concern. I don't think I have a use for this script at this time. — Mathmagician (message wall) 23:19, July 15, 2012 (UTC) Script customization / repurposing Hello! Have to request some advice on customization of this script. As a backstory, I'm taking care of an answers wiki. Most of the activity are forum-like discussions. We endorse certain formatting traditions, which the users need to be continiously reminded of (as the community is fluid and, in a big part, anonymous). I want to repurpose this useful script into a notification about formatting practices. So far, via some hackish tweaks, I got it to work on standard question pages and forum pages, in a manner similar to the original script: page blackout and a dismissal button. However, instead of this, I would like it to only appear in the editor window, not when browsing the pages. It's technically possible: if you remove condition checks from the original script, the notification will appear in the editor, overlapping the formatting buttons (the position is probably adjustable). To get it to work properly, I need a condition check that ensures the window is only displayed in the editor. I can think of several hackish workarounds, like checking if the page belongs to (any) category, but it would be better to accurately check for the editor. Another part I need help with is how to make the notification disappear after a set amount of time, as opposed to having to press a button. Even better, if it faded out soon after being mouse-overed. This would also solve the problem of overlapping the formatting buttons. Since my skills with JS are limited to common sense, any kind of help would be greatly appreciated. I also hope it'll be useful to someone else. I've seen many complaints about people not signing posts properly. It could be made a separate general-purpose script for use on other wikis. Mitranim :The editor already has a mechanism for notices. Do you really want something else entirely? -- pecoes 13:37, July 31, 2012 (UTC) :Do you mean that editor's inbuilt notification is controllable? If this is the case, please tell me how to use it. I was not aware it's possible. Of course, it would be better to use a native method instead of custom workarounds. Mitranim ::I do believe so. I distinctly remember getting custom messages on certain wikis. You probably have to edit certain MediaWiki pages... but which ones, I do not know. You might want to poke around Special:AllMessages a little - especially the ones that start with "edit" should be interesting. You could also ask the Community forums. -- pecoes 14:47, July 31, 2012 (UTC) :::Here's a very distinctive one. You might want to ask this admin what the trick behind it is. -- pecoes 15:16, July 31, 2012 (UTC) ::::And there's also Editnotices. Here's a very simple example: http://pecoes.wikia.com/wiki/NewArticle?action=edit ::::pecoes 15:32, July 31, 2012 (UTC) ::::This possibility is extremely awesome. This is a big help, thank you very much. On to try an implementation. Mitranim It works: http://masseffect.answers.wikia.com/wiki/Test?action=edit http://masseffect.answers.wikia.com/wiki/Template:Editnotice. So far, it worked on nearly every namespace I tried it on. However, I ran into a problem with the forum namespace (110). It just doesn't work on forum pages. I double checked the forum editnotice, and even checked the RC logs to ensure the forumspace on our wiki is still 110 (appears to be accurate). Any suggestions why it might be not working? Mitranim :It worked in the forum too - after I the page. -- pecoes 19:11, July 31, 2012 (UTC) :Haha, that was one thing I was intending to do after getting back from AFK, but you beat me to it. Thanks again! Mitranim "Ask for support", round three. I'm trying to make parts of the edit notice work like edittools, i.e. I want and ~~~ to insert this code on the cursor when clicked. I've wrapped them into tags, but that didn't seem to do the trick. However, I've noticed that if I include either id or class with the word "edittools" into the div properties of the edit notice, the editor will display a notification with the notice text at the top of the page, just like in the talk page example you've linked earlier. When I click on this notification, it brings up a popup window with the edit notice, and there the code is clickable and works like edit tools. But I want it to work similarly on the plain notice to begin with! I'll continue tinkering around with it, but any ideas or suggestions are very welcome. Mitranim :MediaWiki:EditTools works only with the source editor - not with the rich text editor, I'm afraid. :As for the source editor: This is (more or less) what the HTML looks like: ~~~ :Maybe using one of these tags, classes or ids does the trick... :Personally I'd use JavaScript though. The key part is probably this: ~~~ :But you can neither use an a-tag nor an onclick-handler in a regular template. That's only possible in a MediaWiki page. Maybe you can use a MediaWiki page as if it were a template by prefixing it with a colon. I wouldn't know that without testing. If that doesn't work, there might be other ways... -- pecoes 21:12, July 31, 2012 (UTC) :Apologies for the delayed answer. Thanks again for the information. I've created a MediaWiki template and tested it in the user namespace. It actually works! The notice looks fine, and the tools actually insert the code when clicked, which is extremely awesome. However, it has limitations. The template looks messed up due to unsupported tags, and the yellow clickable notification that appears if the div section is tagged with edittools class/id is messed up, too, along with the pop-up window it summons. This is not a problem if I eschew the notification by excluding edittools tags, but it's not a perfect solution. Still, a step ahead. Mitranim ::It's a start :) I may have one or two more tricks up my sleeve. That'll require a bit of experimentation though... Can you make me an admin for an hour or two? -- pecoes 11:28, August 01, 2012 (UTC) ::I suppose I can. (*poof*) Here you go. Just be careful not to mess up anything major. :) Mitranim ::While the notification is useful to grab attention to the notice, I'm not sure I want it overlapping the clickable tools. When a person opens the editor, they might want to click on the tool right away to separate their post from the previous ones, and the notification might get in the way. I guess I'll roll out the experimental version wiki-wide for now, without the notification, and see how it fares. But the bugs are still there. I'll try to tinker with it later in the evening, but if you get any progress, please let me know! Mitranim :::Another update: it took me a while, but I've finally noticed your note that clickable edittools only work in the source editor. I checked, and indeed, the current implementation (that works off edittools' htlm) doesn't work in the visual mode. Inspecting the html for the visual editor tools produces elements like "onclick="CKEDITOR.tools.callFunction(47, this);". I'm afraid it's completely unfamiliar to me, and I have no idea how to implement a solution that would work in both editors at this point. Mitranim ::::Simply put: Wikia does not have any code with which you could insert characters at at the end of the RTE's text field. You would have to write that yourself. I cannot help you with that. At least not any time soon. I do have a relatively good idea, how to do it in the source editor, but I can't seem to get the Editnotice to update ::::I purged: ::::* MediaWiki:EditnoticeTemplate ::::* MediaWiki:Editnotice-0 ::::* and the test article :::: Did I miss something? -- pecoes 14:49, August 01, 2012 (UTC) :::::Still the same thing. None of the changes I made to MediaWiki:EditnoticeTemplate where visible in the test article. I'm starting to think that the contents of the edit page cannot be purged. This may take a while... -- pecoes 16:24, August 01, 2012 (UTC) :::::Editnotices usually refresh instantly and don't require purging (that's what had confused me about the forums that time). I don't know how it's displayed to you, but to me, the changes you've made took effect as soon as I noticed the fact of edits being made. From what I've seen so far, the problem is that the bar that houses the static message (let's call it "the banner") doesn't support any wiki markup whatsoever and only supports HTML tags, while the yellow notification and the pop-up window have perfect support of wiki text but only very limited support of HTML tags. Notably, they don't support . As the result, even if we build the layout through HTML, it seems that there is no way to create clickable links that would be displayed and work properly in both layouts: wiki links will be displayed as raw text in the banner, and HTML links will be displayed as raw code in the notification and in the pop-up window. To get it to work, we need to make it in pure HTML, with HTML tags that are supported in the notification etc, and make it clickable through something else than . Unless of course I'm missing something crucial. Given that you code looks like arcane sorcery to me, I probably am. Mitranim Ah. My mistake. I opened a page in the article namespace - not in the user namespace. I was able to fix it now. It only works in the source editor, of course - but at least that. -- pecoes 17:27, August 01, 2012 (UTC) :Are you absolutely sure it works? For me, it doesn't. The mainspace notice reads "EditnoticeTemplate" (and nothing else), and the userspace message is un-clickable. Mitranim ::Ha. Now you are testing in the article namespace :) Yeah, I had a bit of cleanup left to do. It should work now there as well :) -- pecoes 17:38, August 01, 2012 (UTC) ::Unfortunately, not for me. Here. The mouse cursor didn't quite make it into the screenshot, but it's an edit cursor rather than a pointer, and the tools are definitely not clickable. =/ Mitranim :::W00t! I just figured out how to make it work in the visual editor as well :) It should work in both editors now. I purged everything too, so you should get to see it now - or hopefully soon... -- pecoes 18:27, August 01, 2012 (UTC) :::Huh! I salute to your coding skills. It works indeed, but with an unexpected twist. It's not the server cache's fault. As it turns out, the solution you've implemented doesn't work if the visual editor is disabled in personal preferences. This is how I usually operate, and I use a separate browser instance to check pages in the visual mode. I've purged all the pages several times over, to no avail, then on a hunch headed to my preferences and enabled the visual editor, and this did the trick. With the visual editor enabled, the solution works for both visual and source mode, while without it, it doesn't work at all. Still, it's a step forward since the main purpose of the notification is to make casual visitors follow our formatting practices. I guess I can disable the editor and live with that knowledge. Although it would surely be better to find a solution that works for everyone. :) Mitranim :::So far, it doesn't appear that the last experiments have had any effect (that's probably why you reverted the changes). I wonder if this is something we have control over, or just a bug on Wikia's side. Mitranim ::::Great job detecting that issue with the preferences! :) This has me stumped I'm afraid. It seems I have to subscribe to events of a different editor object. But how exactly to do that only somebody from Staff could tell me. I've send Grunny an email. We'll see... ::::I gotta say: This is really fascinating stuff! I've already discovered two cool things I wish I'd known months ago :) ::::pecoes 20:19, August 01, 2012 (UTC) :::::Grunny got back to me almost immediately. This solution should work now even when the RTE is disabled! :) -- pecoes 21:16, August 01, 2012 (UTC) This is awesome. Thank you for telling me about editnotices and for taking time to work on clickability, Pecoes. Clickable tools are very cool, and add extra convenience, raising the likeness of the code being used. The notification was extremely effective on MEA during the last two days: all of a sudden most anons started using lines and signing their posts. It's potentially useful for other wikis, too. Even if they don't employ specific formatting traditions, it can be used to emphasize the need for ~~~~ on talk pages and conversations, and serve as an easy signature button for lazy ones (who're the problem to begin with). Afaik, there's some kind of code repository here on DW. Maybe a template for the code should be included there? Mitranim